シビックハッカー道場 2023-2-12

後：

Scrapboxにログインする

このプロジェクトに参加する

18:00-18:15：（Scrapboxに書き込みできない人のフォロー）趣旨説明、自己紹介

19:45-20:00：フリーディスカッション

自己紹介

※防窮訓練＝防災訓練のように、貧困におちいっても命を失わないような適切な行動が取れるようになるための短時間の教育プログラム

趣旨説明

勉強会の目的

方法

オンラインで月1回程度の勉強会を行う。さしあたって、①社会、②データ・統計、③プログラミングの3つの分野を扱う （原則30分程度ずつ）。一方的に特定の講師役から習うのではなく、教材をベースに、知識を持ち寄る演習形式とする。興味のある分野を事前に予習し、Scrapboxなどに要点・疑問点・質問を書いておき、当日は議論を中心に進める。

参加者

だれでも参加可能。お誘いあわせの上ご参加ください。

①社会分野

第8章 共同体自治の確立とリーダーの条件

小さなユニットで「われわれ意識」を再構築していく

小さなユニットから行動を起こし、次に、散在する小さなユニットで変化した人々の構えに応じて大きなユニットの問題を考える

テックのプラットフォームを中核とするシステムに支えられたミクロな共同体が、バラバラになった個人を新たに包摂することで、コミューなるな人間関係を再構築していく

このアプローチの成否を握る鍵は、「共同体自治」をいかにして確立するかということ

任せて文句を言うのではなく、引き受けて考える

食とエネルギーが人々が一番参加しやすいテーマ

見えないところに生きている他者や、見えないところに広がる自然生態系に巨大な負荷をかけているのに気づくことができる

「気にかかる仲間」から「全体についての意識へ」と言う経路が大切

共同体自治の確立に向けたプロセスとリーダーシップ

オーナーシップを喚起する

デンマークのサムソ島という人口約4000人の島。

本土の電力会社の電力を使わず、10年間をかけて100%クリーンエネルギー化を実現

人々がエネルギー計画作りに最初から参加し、プロジェクトに投資してオーナーシップを持つことができるようにした。

ビジネスパーソンのトップダウンのリーダーシップでは共同体自治の確立は難しい

「まず自分がみんなにつながる。次にみんなをつなげる。それからみんなに知恵を出してもらう」

共同体自治を実現するためにリーダーは縁の下の力持ちになり、人々に自分たちが主役だと感じてもらう。→決めたことがうまくいかなかったらみんなで修正しようとなる。

ナッジを用いてファシリテートする

妥当な結論を導き出し、仲間意識を生み出す

フリーライダーが出てきてしまうという課題。周囲を混乱させないようにしつつも包摂する。

従来のエリートよりも高い能力が求められるファシリテーターを大規模に養成する必要がある

ミメーシス（この人みたいになりたいと思う気持ち）の惹起

利他的・倫理的である人がミメーシスを惹起できる

本書全体のまとめ

現在の社会には容易に解決できない構造的問題がある

はっきりとした悪役がいるわけではない

安全・安心・便利を推し進めた結果、問題が生じている。完全に元には戻れない

郊外化

システムが全域化する

人間までシステム化され、人々に不安が生じる

孤独感

替えの効く存在としての不全感

人間関係の損得化

「われわれ意識」が喪失した社会の統治

さらにシステム化を推し進めた社会はユートピアかディストピアか？

マクドナルド化とディズニーランド化

システム世界と生活世界の二項対立から脱却し、システムとテックをうまく活用する

人々にオーナーシップを持ってもらう新しいリーダーがこれから必要になる

参加者の質問・感想・コメント

抽象化しすぎているために、個々の歴史や文脈は読み取れない。それぞれの社会の歴史の深掘りも重要か。

哲学や倫理学の基礎づけももっと必要か

いまの行政、企業、NPOなど→トップダウン、自発性重視ではないか

→ただし簡単ではない、試行錯誤

モチベーションかインセンティブか

NPOなどは必ずしもインセンティブ依存ではないが……

モチベーションだけで動く組織は縛る力もそれだけ弱いので運営困難

昔は狭い範囲の共同体、ピアプレッシャーが働いた（村八分）

流動性がほぼない時代（人が入れ替わらない）

都会になると、ピアプレッシャーが働きにくい

オンラインのNPO組織＝そのピアプレッシャーすら働かない、インセンティブなきモチベーションをどう構築するか

身近。他にもありそう。自分たちでやりやすい

感染させていくことが大事か。影響を受けた人の意識が変わって、他の人に影響を与えるようになる。

（早い段階での）教育とシステムの活用が多くの人に影響を与える効果の高い方法かも

システム世界と生活世界の二項対立から脱却し、システムとテックをうまく活用する

人々にオーナーシップを持ってもらう新しいリーダーがこれから必要になる

②データ分野

統計的推測はパラメータ推定の不確実性を理解し、定量化することから始まる

関係する数式と詳細はそれぞれの設定によって変化するが、統計的推測の基礎は統計学全体を通じて同一

→ここを理解すればいろいろと応用がきく！！

本章で扱うこと

母比率（母集団の比率）を推定するために標本比率（標本の比率）を使うというアイディア

信頼区間

仮説検定の枠組み

5.1　点推定と標本による推測の変動性

5.1.1　点推定と誤差

例）アメリカ合衆国大統領の支持率を調べた世論調査

点推定値：調査結果の数字（例：45%）

パラメータ：この場合、母集団全体の比率

推定における誤差：調査による観測結果とパラメータの差

→標本誤差と偏りからなる

標本誤差（sampling error）：ある標本から別の標本へと推定値がどのくらいばらつく傾向があるか（標本の不確実性）

この本の大半を含むほとんどの統計学は、標本誤差を理解し定量化することに焦点を当てている（←標本サイズを考慮することが有用）

偏り（bias）：真の母集団よりも過大または過小推計する系統的な傾向

質問のしかたなどで変化、考え抜かれたデータ収集の手順などで対処

5.1.2　点推定値の変動性を理解する

状況：太陽光エネルギーの利用拡大を支持するアメリカ合衆国成人の比率を知りたい（実際はp=0.88）

このテーマについて、1,000人のアメリカ合衆国の成人を調査する。その調査の標本比率は88%にどのくらい近いと期待してよいだろうか？

コンピュータシミュレーションしてみる（1万回母集団から標本を抽出した結果は図表5.2→標本比率は母比率のとてもよい推定値を与えていることがわかる）

標本分布は現実世界で実際に観測されることはない（何回何回も調査しない）。しかし、標本分布は、点推定値を特徴づけ、意味づけするのに役立つ

5.1.3　中心極限定理

中心極限定理

観測値は独立で、標本サイズが十分に大きいとき、標本比率は次の平均と標本誤差の正規分布に従う傾向がある（p180）

成功・失敗条件：中心極限定理が成立するためには、標本サイズはnp≧10かつn(1-p)≧10が成り立つように通常は十分大きい必要がある

中心極限定理は非常に重要で、多くの統計学の基礎となっている

中心極限定理の技術的な2つの条件：独立性と成功・失敗条件

独立性

例）実験における処置群への無作為割り当て

例）観測値が単純無作為抽出標本からなっている

成功・失敗条件

標本が母集団の10%より大きくないとき、母集団からの標本にはときどき条件が追加されるが、これは任意として考えてよいのでは（そのままだと標本誤差を若干過大推計する傾向があるが、問題になることは非常に稀）

5.1.4　中心極限定理の現実への応用

成功・失敗条件の数式で母比率を使っているが、母比率は全数調査をしない限り知りえない→次善の策として標本比率を使うことばしばしばある（代入原理、plug-in principle）

5.1.5　中心極限定理のより詳細

成功・失敗条件が成立しない場合の例

5.1.6　他の統計量の枠組みの拡張

パラメータを推定するために標本統計量を用いる戦略はごく一般的で、比率以外にも他の統計量にも応用できる

例）ある特定の大学の卒業生の平均給与の推計

例）2つのウェブサイト間の製品価格の違いの推計

5.2　比率の信頼区間

標本比率は完全ではなく、それに関連するいくらかの標準誤差がある

母比率の推定値について述べるとき、点推定の値だけを与える代わりにもっともらしい値の区間を提供することがよりよい実践になる

5.2.1　母集団のパラメータの捕捉

信頼区間：母集団のパラメータを見つけられそうなもっともらしい値の区間を表す

点推定：魚にもりを投げる

信頼区間：網で魚を捕る

5.2.2　95%信頼区間の構築

標本比率は母比率の一番もっともらしい値であることから、点推定値の周りに信頼区間を設定する

標準誤差SEは信頼区間をどのくらい広くすべきかの目安を与えてくれる

標準誤差＝点推定値の標準偏差（母比率とサンプルサイズから計算できる）

95%信頼区間：標本比率から1.96標準誤差の範囲に広がる信頼区間（点推定値の周りに構築するもの）

←標準誤差が点推定値の標準偏差を表しており、中心極限定理の条件が満たされるとき、点推定値は正規分布に近似的にしたがう

←正規分布において、データの95%は平均値から1.96標準誤差の範囲内にある

多くの標本を採取し、それぞれの95%信頼区間を構築したとき、これらの区間の約95%がパラメータpを含んでいる

まとめ：点推定値の分布が中心極限定理の前提を満たし、正規分布に近似的に従っているとき、次のように95%信頼区間を設定できる

点推定値±1.96×SE

5.2.3　信頼水準の変更

99%信頼区間：点推定値±2.58×SE

x%信頼区間：点推定値±z×SE

誤差の範囲：信頼区間において、z×SEは誤差の範囲とよばれる

5.2.4　さらなるケース分析

母平均のような他のパラメータに関しても信頼区間を設定することができる

点推定値±誤差の範囲

5.2.5　信頼区間の解釈

信頼水準

〇与えられた区間にパラメータが存在している確からしさを定量化したもの

×母集団のパラメータを捉える確率

〇信頼区間は母集団のパラメータについてのもの

×個別の観測値や点推定値については何も言っていない

ここで議論した手法は標本誤差に対して応用するものであり、偏りについてではない

偏りに対しては慎重なデータ収集方法に頼ることになる

5.3　比率の仮説検定

Q. 世界で、何らかの病気に対して予防接種を受けている1歳児は現在どのくらいいるか

A. （20% / 50% / 80%）

本節では、4年生大学卒業生の正答率を仮説検定として探求していく

仮説検定は、両立しない考えや主張を厳密に評価するときに使用される枠組みである

5.3.1　仮説検定の枠組み

世界全体の保健の問題とその進歩について、人々が多くを知っているかどうかを調べたい

H0：人々はこれらの特定の問題を学んだことはなく、彼らの回答は単なるあてずっぽうと同等だろう

H0：p＝0.333

HA：人々はでたらめに推測したり、または実際にはおそらくそれよりもさらに正答率が悪化する誤った知識に比べれば、正答率をよりよくするために役立つ知識を持っている

HA：p≠0.333

これらの両立しない考えを仮説という

H0＝帰無仮説（添え字の0の発音はノート（nought）、全体でエイチノート）

懐疑的な視点、検証すべき主張、「差がない」という観点をたびたび表す

HA＝対立仮説

検討中の主張、あらたなまたは強力な視点を表し、可能なパラメータの範囲によってたびたび表される

対立仮説を採用する前に協力な証拠が必要であるという懐疑論的な立場にデータサイエンティストは立っている

帰無仮説を棄却することに失敗するとしても、通常は帰無仮説を真であると認めることにはならない

5.3.2　信頼区間を用いた仮説検定

上記の仮説を検定するために、50人の大学卒の成人のデータを用いる

24%が正解

→33.3%との乖離は偶然？

95%信頼区間は、標本比率±z×SE→(0.122, 0.358)

帰無値p=0.333は信頼区間内にある。つまり、信じがたいとは言えない。このデータは、大学卒の成人の正答率はあてずっぽうとは違うという見解を棄却するには十分な証拠になっておらず、帰無仮説H0は棄却されない

統計学では二重否定を使うことがある

例）帰無仮説は疑わしくはない、帰無仮説を棄却できなかった

ある見方を否定しない一方で、正しいとも言わないことを伝えるために使用される

5.3.3　意思決定の誤り

第1種の過誤：帰無仮説が真であるときにH0を棄却すること

第2種の過誤：対立仮説が真であるときに帰無仮説を棄却しないこと

一方の誤りを減らそうとすると、一般的には他方の誤りを増やす

信頼区間が帰無仮説を棄却するかどうかを決定するのに有用であるが、信頼区間アプローチはいつでも使えるわけではない

例）複数の比率が等しいという仮説を評価したいとき

→p値（p-value、確率値）と呼ばれる統計量を導入、証拠の強さをより理解することを可能にし、後の節のより複雑なデータのシナリオで役立てることができる

5.3.4　p値（確率値）を使う形式的な検定

p値は対立仮説を支持し帰無仮説に反する証拠の強さを定量化する方法

統計学的仮説検定は信頼区間に基づく意思決定よりもどちらかというと通常はp値を使用する

p値を使用する方法を仮説検定の評価に用いるとき、標本比率の代わりに帰無値p0を使って標本比率の条件を確認し、標準誤差を算出する

p値を使用する仮説検定で、帰無仮説が真であることを仮定するが、これは信頼区間を計算するときとは異なる考え方になる。これが、帰無仮説の条件の確認と標準誤差の計算のときに、p̂の代わりにp0を使用する理由である

帰無仮説の下で標本分布を考えるとき、その分布には帰無分布（null distribution）という特別な名前がつけられている。もし、帰無仮説が真であったなら、p値は観測された標本比率の確率を表している

p値を求めるには、一般的には帰無分布を見つけて、点推定値に対応しているその帰無分布の裾部分を見つけることになる

仮説検定の4ステップ

準備：関心のあるパラメータを特定し、仮説を設定し、有意水準を決め、p̂とnを決定する

確認：H0の下でp̂を正規分布で近似できることを保証する条件を確認する。比率の仮説検定では成功・失敗条件を確認するためには帰無値を使用する

計算：条件が成立したら、再びp0を用いて標準誤差を計算し、点推定値のZスコア（検定統計量に当たる）を計算し、p値を決定する（p208例題参照）

結論：p値と有意水準αを比較することにより仮説検定を行い、問題の状況に照らした結論を出す

5.3.5　有意水準の解釈

検定のための有意水準の選択は多くの状況で重要で、伝統的水準はα＝0.05

しかし、応用に基づいて有意水準を調整することは有用

検定から得られる結論の重要性に基づいて、有意水準を0.05より小さくしたり大きくしたりしてよい

第1種の過誤を犯すことが危険あるいは特にコストがかかる場合は、小さな有意水準（たとえば0.01）を選ぶべき

第2種の過誤を犯すことが、第1種の過誤よりも相対的に危険あるいははるかにコストがかかる場合は、より大きな有意水準（例えば0.10）を選んでもよいかもしれない

第2種の過誤のコストに比べてデータを収集するコストが小さい場合は、より多くのデータを集めることはよい戦略→第2種の過誤は軽減、第1種の過誤には影響しない

なぜ有意水準は0.05が既定値なのか：www.openintro.org/why05

5.3.6　統計的有意対実務的有意

サンプルサイズが大きくなると、非常に小さな差であっても統計的有意となることがある

例）映画批評サイトでの追加的な広告を出すと、テレビ番組の視聴率を0.001%有意に増加させるというオンラインの実験結果

しかし、実務的には価値はない

標本サイズの計画

実際に意味のある違いがあるのであれば、研究者はそれを見分けるのに十分大きい標本サイズを提案することができる

5.3.7　片側検定（special topic）

ここまで、pが帰無値p0よりも上または下であるかどうかを判定する両側検定（two-sided hypothesis tests）だけを考えてきた

このほか、片側検定（one-sided hypothesis test）もある。pがp0より小さいときだけ、あるいは大きいときだけ意味がある検定

メリット：p値が小さくなり、対立仮説が入っている範囲の興味ある知見を特定するために必要な証拠の水準は下がる

デメリット：対立仮説とは逆の興味深い発見が無視されるという重い代償を支払う

→本書では以後は両側検定のみを扱う

参加者の質問・感想・コメント

③プログラミング分野

第６章　エラー処理

6.1　プログラムも失敗する

例外処理はJava、C++、Python、Rubyなど現代の多くの言語でサポートされている

プログラミング言語においても、「失敗を伝える仕組み」は重要

6.2　失敗をどうやって伝える？

エラー処理の書き方には主に二種類ある

１．返り値を使って失敗を伝える方法

成功したときには０を返し、失敗したときにはそれ以外（返り値）を返すことで、「失敗したときはここに書くよ、あとでチェックしておいてね」と伝える

問題点

失敗を見落とす

プログラマが返り値チェックを忘れてしまい、「処理は成功した」と思い込んだコードを書いてしまう

コードを書いたタイミングと問題が発覚するタイミングが離れてしまうので、コードの問題点を確認するのが大変

エラー処理のせいでコードが読みづらい

「本来やりたいことを記述したコード」の間にたくさんの「失敗したときのためのコード」が挟まって読みにくくなってしまう

対処法

ジャンプでエラー処理をまとめる

「失敗したときの処理」はERRORへのジャンプが起きた時のみ実行される

２．例外を使う方法（例外処理）

例外処理が誕生する以前は、「失敗したらジャンプする」という処理で対処していた

エラーが起きた時にジャンプする場所を事前に登録しておくという方法

UNIVAC Ⅰの場合

1950年に作られたコンピューター

計算してオーバーフローが起きた場合に、000番地に置かれている命令を実行するという機能

COBOLの場合

2種類のエラー処理が存在

READでファイルから読みだす際に、「AT END」という句で「もうデータがない」などのエラーが起きた時の処理を書く構文

ADDなどで数値の加減乗除を行う際に「ON SIZE ERROR」という句でオーバーフローなどのエラーが起きた時の処理を書く構文

PL/Iの場合

1964年に登場

例外処理を行うON構文が導入

先に失敗したときの処理を書いて登録し、それから失敗しそうなコードを書く

6.3　失敗しそうなコードを囲む構文

John Goodenoughの主張

プログラマがした失敗をコンパイラが警告できるようにするためには、２つのものが必要

①命令がどういう例外を投げる可能性があるかを明示的に宣言させること

②字句的に「失敗しそうな処理」を囲む構文

CLUへの導入

プログラミング言語CLUは例外処理のメカニズムを導入

命令の後ろにエラー処理を各except構文が追加される

⇒「失敗しそうな処理を囲んで、それにエラー処理をつける」という書き方ができるように

C++への導入

1983年に登場

失敗しそうなコードを囲むブロックの頭にtry、失敗を捕まえて処理するブロックの頭にcatchというキーワードを囲む構文を追加

例外を発生させる命令にはthrowが選ばれた

Windows NT3.1への導入

1993年にリリース

構造化例外を導入

__try、__except、__finallyというキーワードが存在した

6.4　出口を一つにしたい

なぜfinallyを導入したのか

構造化例外処理を導入することで、コードの信頼性が高まる

対になる処理を確実に行いたい

プログラミングには多くの対になる処理がある

ファイルを開いて閉じる、ロックをかけてあとで外すなど

対になる処理のエラー処理を、返り値のチェックやgotoを使わないで簡潔に行いたい

finallyによる解決

処理はtryブロックから離れる際にfinallyブロックは必ず実行される

finallyのないC++では、RAIIというテクニックを使うのが一般的

その対象を扱うためのクラスを作り、そのコンストラクタで開き、ディストラクタで閉じる

D言語のscope（exit）による解決

スコープガードを使うことで、スコープ（関数など）を抜ける際に行う処理をあらかじめ登録する

6.5　どういうときに例外を投げるか

2000年頃は、「例外は例外的な状況にのみ限定すべき」と言われていた

例外的な状況とは

関数呼び出し時に引数が不足している場合

配列の範囲外を取得しようとした場合

間違えたらすぐに例外を投げてほしい

フェイルファースト：「おかしくなったら処理を停止して速やかに報告すべき」という設計思想

6.6　例外の伝搬

多くの例外処理では、例外が呼び出し元に伝搬する

例外が伝搬する問題点

呼び出し元から呼ばれる全ての関数のソースコードを見なければ、呼び出し元がどんな例外を投げる可能性があるのか分からない

Javaの検査例外

Javaでは「例外」を３つに分類している

例外処理すべきではない重大な問題

例外処理してもよい、実行時例外

例外処理してもいい、それ以外の例外（検査例外）

もしメソッドの外に投げるのであれば、それをメソッド定義時に宣言する必要がある

検査例外が普及しない理由

とにかく面倒くさいから

第７章　名前とスコープ

7.1 名前はなぜ必要だったか

名前の誕生以前：番号（メモリの番地）が使用されていた

人間にとっては、名前で対象を指定できた方が楽

どうやって名前を付けるか

コンピュータが名前とモノ（オブジェクト）の対応表を持てばよい

名前の衝突

変数はグローバルスコープ（グローバル変数）である：

プログラム全体で一つの対応表が使われている＝変数の名前が有効な範囲がプログラム全体である

⇒書き換えるたびにその影響がプログラム全体に及ぶ

⇒変数名がうっかり重複すると無限ループが発生してしまう（衝突してしまう）

衝突を回避するには

長い変数名をつける

スコープを利用する

7.2 スコープの進化

スコープ：名前の有効範囲

動的スコープ：関数の入り口で元の値を取っておき、出口で書き戻す

複数の関数で対応表を共有

問題点：変数を書き換えてから別の関数を呼び出した場合、呼び出された関数に影響が及ぶ

書き換えた値を読めるが、書き換える前の値が読めない

静的スコープ：関数ごとに対応表を分ける

⇒ひとつの関数の中での変更が、その他の関数に影響を与えずに済む！

7.3 静的スコープは完成形？

Pythonのスコープは三階層

ビルトイン：プログラム全体で一個の対応表

グローバル：ファイル単位での対応表

ローカル：関数ごとの対応表

静的スコープの問題点

ネストした関数の問題：入れ子になったように見えるスコープが実際には入れ子になっていない

⇒Python2.1からは仕様修正

外のスコープへの再束縛の問題：ネストしたスコープの外側の変数を変更できない

Pythonでの解決方法：関数冒頭で変数を「nonlocal」だと宣言する

Rubyでの解決方法：同じ名前を使っていないか注意する

第８章　型

8.1 型とは何か

型：人間がデータに付けた「追加のデータ」

「どういう種類の値であるか」という情報をビット列に追加したもの

8.2 数値をオンとオフで表現する方法

コンピュータの中に保存されているデータは、オンとオフ、0と1の集まりで表現されている

「数をどうやって表現するか」の歴史

825年：インドで位取り記数法の発明

1908年：７セグメントディスプレイが特許出願

そろばんによる記述

8.3 １つの位に必要なランプはいくつか？

１つのランプでは２通り、２つでは４通り、３つでは８通り、４つでは16通りが表現できる

ランプ４つで16通りが表現できるのに、10進法を使うのは勿体ないので、２進法を使う

２進法を使うと10個のランプで0から1023まで表現できるので、効率がいい

２進法の何文字かをまとめて１文字にする（８進法や16進法を使う）ことで、人間にとって読みやすい表現にすることができる

8.4 実数はどうやって表現しよう

固定小数点：小数点がどこに付くか決める

例えば、下一桁を小数部にするなど

⇒「どこまでを小数部に決めたか」を忘れてしまう問題も

浮動小数点：どこからが小数部かの情報自体を値に含める

例えば、16個のランプで0～1023まで表現できるので、これで有効数字３桁の情報を表現するのに使い、残りの６個のランプで0～63が表現できるので、これを小数点の位置を表現するのに使う

今ではIEE754で決めごとが標準化されている

最上位ビットの「符号」＋小数点位置の「指数部」＋有効数字の小数点以下の部分の「仮数部」で構成

8.5 型は何のため？

コンピュータにとって整数と浮動小数点数はまったくの別物

人間にとって整数「７」と少数「7.0」は同じであるが・・・

⇒コンピュータはビット列だけでは、それを「整数」と解釈するべきか、「浮動小数点」として解釈するべきかわからないので、別途、「この値はどういう種類なのか」という情報が必要

初期のFORTRANでは、変数名の戦闘が１～Nなら整数、それ以外は浮動小数点が入っているというように、変数名の中身に関するルールを決めて対応していた

もう一つの対応策は、言語処理系に「この変数は整数ですよ」と教えて、コンピュータに覚えさせること

⇒変数の型の宣言の誕生

言語によって「x + y」と書かれた場合の、暗黙の型昇格（整数　or 浮動小数点）は異なる

8.6 型の色々な展開

ユーザ定義型とオブジェクト指向

ユーザ定義型：言語が用意している基本的な型を組み合わせて、新しい型を作る

(ex)C言語

オブジェクト指向：整数などの「データ」だけでなく、関数などの「データがどう処理するか」もゆーぁが定義できる型にまとめる（「クラス」を作る）

(ex)C++やJava

仕様を型で表現すれば、仕様に合致しているかはコンパイラがチェックしてくれるので、仕様は最小限だけを公開するように

さらに、具体的な実装を持たない型（Javaのインタフェースなど）や、「関数が例外を投げるかどうか」の情報も型に含める言語も登場

ただし、型で表現されていない情報もあるので、今でも人間がドキュメントやソースコードを確認する必要がある

総称型、ジェネリクス、テンプレート

総称型：構成要素の型の一部が変わる型＝型を引数にとって型を作る関数

型を部分的に再利用したいというニーズに対応

(ex)C++のテンプレート、Javaのジェネリクス、Haskelの型のコンストラクタ

動的型付け：「種類の情報」と「値」がセットになっている

（⇔）静的型付け

Pythonにおいては、整数でも浮動小数点でも文字列でも、すべてPyObject型の構造の中に、値の種類の情報を入れる場所が用意されている（値の先頭部分がすべて同じ形）ので、型宣言が不要になる

型推論：コンピュータが型を推論することで、コンパイル時の型チェックは捨てずに、面倒くさい型宣言は減らすというアプローチも

参加者の質問・感想・コメント

次回担当

5章

6-9章

社会：『入門貧困論』

課題：次の社会分野の文献を提案！

作者やキーワードだけでも

★金子 充 「入門貧困論」

香取 照幸 「教養としての社会保障」

次回3月12日18時～